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(57) Abstract: A message distribution center (MDC) (100) and Intelligent Delivery Agent (318) are implemented in a wireless 
Internet gateway interposed between content providers ( 120) and a wireless carrier (130) to subjectively examine and direct messages 
via SMTP based on desired rules using standard SMTP Gateway and other well-known protocols. The MDC (100) includes an 
individual queue for each subscriber, and the provider is informed through conventional SMTP protocol messages that the short 
message has been accepted. If the carrier has specifically disallowed service for a particular MIN, then the content provider (120) 
is informed through an SMTP interchange that the recipient is invalid An MDC (100) provides a single mechanism for interacting 
with subscribers of multiple carriers (130), regardless of each carrier's underlying infrastructure. In the disclosed embodiment a 
content provider (120) communicates with the MDC (100) using SMTP protocol messages, and the MDC ( 100) communicates with 
wireless carriers (130) preferably using RMI/SMPP techniques. 
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INTELLIGENT DELIVERY AGENT FOR SHORT MESSAGE 
DISTRIBUTION CENTER 

BACKGROUND OF THE INVENTION 
5 1. Field of the Invention 

This invention relates generally to wireless carriers, Internet 
service providers (ISPs), and information content delivery services/providers. 
More particularly, it relates to Wireless Telecommunication, ANSI-41D 
Wireless Intelligent Network (WIN) applications, and SMTP protocol to 
10 manage information content for a wireless carrier. 

2. Background of Related Art 

There are many "wireless" information content providers in the 
industry who have some information or service that is considered of value to 
15 the mobile phone user. Wireless Carriers are typically in favor of these 
content providers as they add* value to Short Messaging Systems (SMS) and 
can drive up SMS and voice usage. 

Unfortunately, content providers may not fully understand a 
particular wireless network and/or may not be fully sensitized to particular 
20 needs of carriers. This is because the carrier is often seen simply as a 'pipe 1 
through which wireless messages are sent using SMTP protocol. Content 
providers maintain their own subscriber lists, and typically communicate with 
carriers merely as e-mail hosts. 

All traffic is typically sent through an SMTP gateway, and thus 
25 information content, ads, etc., cannot be differentiated from higher priority 
'personal' content. Problems arising from this include: 

Bulk information content can slow down and even 
jeopardize the carrier's SMTP Gateway performance; 

Personal messages cannot be given a higher priority than 
30 bulk messages; 

Bulk info content receives the same messaging 
parameters as personal messages, e.g., delivery receipts 
enabled, expiration date of 3-5 days, etc.; 
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The carrier cannot differentiate between bulk messages 
among various providers and personal mail for billing purposes; 

Bulk senders deliver their content regardless of whether 
the device is on, and thus the carrier must handle message 
5 storage and retry attempts; and 

Bulk senders will typically continue to deliver content to 
churned wireless subscribers, wasting network resources and 
interfering with reuse of mobile numbers. 
There is a need for a technique using SMTP and/or other 
io conventional protocols to enable an easy way for content providers to 
distribute and/or differentiate their information without requiring them to 
change technologies. 

BRIEF DESCRIPTION OF THE DRAWINGS 

15 Features and advantages of the present invention will become 

apparent to those skilled in the art from the following description with 

reference to the drawings, in which: 

Fig., 1 shows a high level sequence • diagram including a 

Message Distribution Center (MDC) enabling a Content Provider to direct 
20 messages via SMTP to the Message Distribution Center (MDC), in 

accordance with the principles of the present invention. 

Fig. 2 illustrates exemplary software components and their 

relationships in an embodiment of a message distribution center (MDC), in 

accordance with one embodiment of the present invention. 
25 Fig- 3 is an exemplary class diagram which shows further details 

of an embodiment of a Message Distribution Center, in accordance with the 

principles of the present invention. 

SUMMARY OF THE INVENTION 

30 ln accordance with the principles of the present invention, a 

message distribution center is interposed between a source of a short 
message and a wireless network including an intended recipient of the short 
message. The message distribution center comprises an SMTP protocol 
communication channel to receive the short message from the source of the 
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short message. A plurality of subscriber queues are Included, each 
corresponding to a different subscriber in the wireless network. The short 
message is placed In at least one of the plurality of subscriber queues before 
delivery to the wireless network. A communication channel communicates the 

5 short message to the wireless network. 

In accordance with another aspect of the present invention, a 
method of throttling short messages to subscribers in a wireless network 
comprises forwarding a short message to a wireless network only when a 
receiving wireless device in said wireless network is known outside said 

10 wireless network to be online. 

DETAILED DESCRIPTION OF ILLUSTRATIVE EMBODIMENTS 

The present invention enables a. Content Provider to direct 
messages via SMTP to an intermediatary Message Distribution Center (MDC) 

15 using standard SMTP Gateway and other well-known protocols. 

In accordance with the principles of the present invention, short 
messages are inserted in the MDC into individual queues for each subscriber, 
and the provider is informed through conventional SMTP protocol messages 
that the short message has been accepted. 

20 If the carrier has specifically disallowed service for a MIN (e.g., 

in the case of churning), then the content provider is informed through an 
SMTP interchange that the recipient is invalid. This encourages providers to 
discontinue service to terminated MINs, thereby reducing traffic to the MDC. 

A Message Distribution Center (MDC) provides value to both 

25 wireless developers and wireless carriers. For instance, for the Wireless 
Developer, an MDC provides a single mechanism for interacting with 
subscribers of multiple carriers, regardless of each carrier's underlying 
infrastructure. For the earner, an MDC can protect their SS7 network by 
intelligently throttling messages and configuring message delivery parameters 

30 to be more network friendly. 

An MDC acts as a broker between carriers and developers. 
Different levels of relationships can be established with both carriers and 
developers, resulting in different levels of services that are available. The 
MDC interacts with a carrier's Short Message Service Center(s) (SMSCs) 

3 
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and/or SS7 network, allowing developers to guarantee message delivery, to 
interact with users via Mobile Terminated (MT) and Mobile Originated (MO) 
SMS, and possibly even to receive handset presence Information. 

Although the disclosed embodiments relate primarily to wireless 
5 services from the perspective of a Short Message Service (SMS), the 
disclosed MDC and related management middleware may support many 
types of wireless devices using the same API. For instance, suitable 
supported devices may include, e.g., 2-way Email pagers, the Palm VII™, and 
wireless application protocol (WAP) devices. 

10 The disclosed MDC utilizes a Wireless Internet Gateway (WIG), 

which is a middleware messaging platform designed to facilitate 
communication between Internet devices and various wireless networks. A 
suitable WIG is disclosed in U.S. Appl. No. 09/630,762 to SMITH, entitled 
"Wireless Internet Gateway", filed August 2, 2000, the entirety of which is 

is expressly incorporated herein by reference. 

Fig. 1 shows a high level sequence diagram including a 
Message Distribution Center (MDC) enabling a Content Provider to direct 
messages via SMTP to the Message Distribution Center (MDC), in 
accordance with the principles of the present invention. 

20 In particular, as shown in Fig. 1, an MDC gateway (MDC) 100 

and Intelligent Delivery Agent (IDA) 318 are placed intermediary between a 
content provider 120 and a wireless carrier 130, to allow management of 
message delivery for each of a plurality of subscribers. 

There are two main programs. The first application program is 

25 the MDC Gateway 100, which is essentially a Wireless Internet Gateway to 
check for and process information provider messages as shown and 
described herein. The second application program is the Intelligent Delivery 
Agent (IDA) 318. 

As shown in Fig. 1, the content provider 120 communicates with 

30 the MDC 100 using SMTP protocol messages, and the MDC communicates 
with the wireless carrier 130 preferably using RMI/SMPP techniques. A 
plurality of configuration files 500 configured by an appropriate system 
administrator control parameters In the MDC 100 and IDA 318. 

4 
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Importantly, the MDC 100 includes a plurality of subscriber 
queues 150, preferably one for each subscriber having MDC support. The 
subscriber queues 150 may be integratedwithin the gateway of the MDC 100, 
or may be external to the gateway of the MDC 100 but nevertheless in direct 

5 communication with the gateway of the MDC 100. 

The subscriber queue 150 preferably follows a First In First Out 
(FIFO) model, where the oldest messages are delivered first. 

In accordance with the principles of the present invention, a 
particular wireless carrier 130 assigns a value for the maximum number of 

io outstanding messages for a particular subscriber. This maximum number of 
outstanding messages can be used to establish a queue threshold. Thus, if 
one or more new messages cause the queue threshold to be exceeded, then 
the oldest messages may be deleted first from the particular subscriber queue 
150 to make room for the new message(s). Of course, the subscriber queue 

is 150 may be expanded in size as desired. To provide protection 

from constantly growing subscriber queues 150, other rules may be 
established by the wireless carrier 130 to allow automatic deletion of particular 
messages from the subscriber queue 150. 

For instance, an expiration period may be established whereby 

20 all messages more than x days old are removed. The expiration period may 
be established, e.g., on an individual subscriber basis (e.g., different 
subscription plans allowing larger queues and/or longer storage times), or on 
a global basis (e.g., all subscribers in a particular wireless network have a 
similar expiration time). 

25 The use of automatic deletion of short messages from 

subscriber queues 150 is important, e.g., in the case of churned MINs, so that 
a new subscriber does not receive lingering messages from a previous 
subscriber with the same MIN. 

Short messages to subscriber queues 150 may be delivered 

30 independently from one another and/or message delivery times spaced apart, 
thereby distributing message load over time and minimizing the negative 
effects of batch messaging on the wireless network. 



5 
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The MDC 100 can also or alternatively be configured to avoid 
sending batch messages during the carrier's busy hour(s), thereby minimizing 
load pressures on the wireless network. 

The use of an MDC 150 can aid the wireless carrier's network 
significantly, e.g., by forwarding short messages only when the relative 
handsets are turned on. Under this scenario, subscriber queues are not 
processed when the handset is powered off. This can reduce network 
storage requirements, delivery retry attempts, and overall SS7 usage. The 
MDC 100 can do this either by interacting with appropriate applications, e.g., 
with a mobile chat location register (MCLR), or generally by intelligent use of 
SMS delivery receipt data from the SMSC and Web Gateway. A suitable 
mobile chat location register (MCLR) is shown and described in U.S. Appt. 
No. 09/814,363, entitled "Wireless Chat Automatic Status Tracking", filed 
March 23, 2001 by Ung et al., the entirety of which is expressly incorporated 
herein by reference. 

The MDC 100 can further be configured to send content from 
various providers to certain SMPP ports on a short message service center 
(SMSC). The receipt of such content allows distinct billing records to be 
generated for each type of service, e.g., ads, general content, premium 
content, etc. 

Fig. 2 illustrates exemplary software components and their 
relationships in an embodiment of a message distribution center (MDC), in 
accordance with one embodiment of the present invention. 

In the disclosed embodiments, a Wireless Internet Gateway 
(WIG) was modified to include another 'dev/nuir destination, which 
acknowledges short messages from a queueMonitor, but does not actually 
process them. The short messages remain in the Messages table of the 
database, where they are retrieved by a software component referred to 
herein as an "Intelligent Delivery Agent" (IDA). 

The IDA retrieves messages from the Messages table in the 
database for subscribers, e.g., when they power on their handsets, subject to 
any desired rules. The IDA can become aware of subscriber power-ups 
through any appropriate trigger, e.g., via an SMPP Delivery Receipt 
mechanism, through Mobile Chat Location Register (MCLR) software, etc. 
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Preferably, the IDA throttles short message traffic to any or all subscribers, 
e.g., optionally waiting until the busy hour is over before beginning the 
transmission. 

The MDC Gateway 100 may be, e.g., a standard WIG to which 
5 the provider sends messages through SMTP, RMI, HTTP, or suitable 
middleware software. As shown in Fig. 2, the MDC 100 includes a new 
DummyDestination, which simply acknowledges receipt from a particular 
subscriber queue 150, but does not attempt delivery. Delivery may be 
accomplished through an Intelligent Delivery Agent process, which polls a 

10 messages table that is populated when the MDC Gateway 100 receives 
relevant short messages. 

To most efficiently use the MDC gateway 100, the SMTP 
session preferably assigns the msgType property based on the sender's 
Email address and using InfoProviders information from the database. This 

is allows the MDC Gateway 100 to determine that SMTP messages from an 
Information Provider (e.g., INFO@NEWS.COM ) should use the Dummy 
Destination and be queried by the IDA. If the short message is submitted via 
an RMI mechanism, then the sender will explicitly define the msgType. 

When the MDC 100 inserts a short message record, an 

20 Oracle™ trigger may be used to create a subscriber record in the Subscribers 
table in the database if such a record does not already exist for the recipient. 

The Subscribers table may contain, preferably at a minimum, a 
MIN, status (e.g., 'Online', 'Offline 1 , 'Unknown 1 ), and the time of the last status 
update. When first created, the status may default to 'Unknown 1 . 

25 The IDA may be a separate program that delivers messages 

from the database to appropriate recipients via a RemoteSMPP RMI Interface 
of the carrier's gateway. The IDA preferably determines subscriber availability 
via, e.g., an MCLR or via Delivery Receipts. The former approach is likely 
more efficient, but the latter approach is more likely to work with most carrier 

30 environments. 

The Delivery Receipt method Is considered to be more 
complicated. The Delivery Receipt method attempts to find the status of a 
subscriber's handset by examining delivery receipts from messages sent to 
the subscriber. 

7 
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As shown in Fig. 2, a SubscriberPoller agent 202 starts the 
process by gathering a list of subscribers from a Subscribers table 214 at 
some time interval (z). If a particufar subscriber is online, then the 
DeliveryAgent object 210 Is notified. 

5 The DeliveryAgent 210 then gathers some pre-configured 

number of messages in time order for the subscriber from the Messages table 
228 in the database, and sends them to the Carrier gateway 238 for delivery 
to the subscriber. There is no delivery receipt associated with these 
messages, so if the subscriber's handset Is turned off the short messages are 

10 not delivered and not resent. This Is why it is preferred that only a pre- 
configured number of short messages be sent before the subscriber's status 
is checked again by SubscriberPolter 202. 

If a subscriber's status is unknown, then a DRDeliverAgent 234 
is notified to send one message via the Carrier gateway 238 to the subscriber 

is with a delivery receipt requested. When it sends the message, it sets Ihe 
subscriber status as offline so that the SubscriberPoller 202 will ignore that 
subscriber. 

The delivery receipt will arrive at DR Listener 208. If the delivery 
receipt indicates failure, then the subscriber status is set as 'unknown', 

20 otherwise the subscriber status is set as 'online'. The SubscriberPoller 202 
wakes up shortly thereafter to take advantage of the user going online. 

Because there Is no direct feedback from the handset, there is 
no conventional information received when a handset is turned off or on. 
DBSubStatusResetter 204 makes assumptions about how long a handset 

25 typically stays on or goes off. If a handset has been marked as online for a 
period of time (x), then DRSubStatusResetter 204 sets the corresponding 
subscriber status to 'unknown', which will restart the delivery receipt cycle 
again. If a subscriber has been marked as 'offline' for a different period of 
time (y), then the subscriber Is marked as unknown, again restarting the 

30 delivery receipt cycle. 

To summarize, there are three time periods involved in the 
Delivery Receipt method. Time x is the average time that a handset is online. 
Time y is the average time that a handset is offline. Time z is how often the 
Subscribers table 214 is polled for a list of subscribers. 

8 
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The three periods mentioned (x, y, and z) must have a certain 
relationship to one another; Time z must be smaller than time x and time y. 
Time x and time /s relationship to one another doesn't matter. Time z must 
be smaller than time x so that when a subscriber goes online, messages are 
5 sent to it before time x expires and online subscribers are set to 'unknown'. 
Time z should be smaller than time y, otherwise the subscriber will be sent 
another message before DR Listener 208 has had a chance to receive the 
delivery receipt. This implies that time z will also be longer than the expected 
time for a delivery receipt. 

10 A SubscriberCleanilp agent may be implemented to clean out 

subscribers that haven't had messages sent to them for a pre-defined period 
of time. This will ensure that the subscriber database doesn't grow without 
bound. Subscribers may have taken their name from the information 
provider's subscriber list. 

15 Another technique mentioned above is to use an MCLR facility. 

In this situation, the MCLR will know explicitly when a handset is turned off or 
on. The MCLR Listener 218 then updates the Subscribers table 214 
accordingly. The SubscriberPoller 202 always sees only online subscribers. It 
then uses the DeliveryAgent 210 to send the messages without a delivery 

20 receipt requested. 

When the MCLR Listener 218 is active, then the 
DRDeliverAgent 234, DR Ustener 208, and DBSubStatusResetter 204 are all 
inactive. When the three delivery receipt entities are active, then the MCLR 
Listener 21 8 is inactive. 

25 The IDA Main 232 activates appropriate facilities based on a 

configuration file. 

In an MCLR implementation, the DRDeliveryAgent 234, DR 
Listener 208, and DRSubStatusResetter 204 may not be used. 

Fig. 3 is an exemplary class diagram which shows further details 
30 of an embodiment of a Message Distribution Center, in accordance with the 
principles of the present invention. In particular, Fig. 3 shows exemplary 
classes that may be activated and used to determine subscriber status and to 
actually deliver messages. 

9 
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As shown in Fig. 3, an IDA main class 318 is responsible for 
deciding which subscriber status determination strategy to use. The IDA 
class 318 may receive this information from a configuration file. The IDA 
class 318 instantiates and activates an MCLRListener class 314 if that facility 
5 is to be used to retrieve a handset's online/offline status. If the strategy is to 
use delivery receipts, then the IDA class 318 instead instantiates and 
activates the DRUstener 322 and DRSubStatusResetter 316 classes. 

A SubscriberPoller 306 class gets a list of subscribers whose 
status is 'unknown' or 'online' from the database. If a subscriber's status is 
io 'unknown', the SubscriberPoller 306 invokes a method in a DeliveryAgent 
class 302 to send a message requesting a delivery receipt. If the subscriber's 
status is •online', then the DeliveryAgent 302 sends messages without a 
delivery receipt to the subscriber. 

The DeliveryAgent 302 is responsible for averaging out the load 
is on the earner's system. It may do this by spreading out the messages over 
time, allowing normal traffic to be sent more quickly. The DeliveryAgent 302 
may also hold off sending batch messages during the carrier's busy time. 
This information may be maintained in a configuration file and retrieved 
through a DetiverySetuplnfo class. 
20 "The DeliveryAgent 302 can also be configured to send 

messages over certain SMPP ports to the carrier gateway 238 for tracking the 
amount of traffic that an information provider is sending. The DeliveryAgent 
302 may accomplish this by tagging the message with a message type 
indicating that it is an MDC message. The configuration file may be set up so 
2S that messages of an MDC type will be sent to certain SMPP ports by the 
carrier gateway 238. 

Both the Subscribers 300 and Messages 304 classes may be 
wrappers around their respective database tables, to isolate JDBC calls to 
these classes only and/or to place the data in a useful format. 
30 1116 'DA 318 may send messages and/or decide blackout 

periods on a global basis, i.e., regardless of the destination of any particular 
message. One enhancement to this is to apply these on a per-carrier basis 
since carriers can be In different time zones or have more or less capable 
hardware. 

10 
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One advantage provided by the present invention is that SMTP 
is a well-known protocol and an easy way for content providers to distribute 
their information. 

A Message Distribution Center (MDC) in accordance with the 
5 principles of the present invention provides an ideal solution. It addresses the 
problems faced by the carrier without requiring the information providers to 
change technologies. 

The principles of the present invention have applicability for 
usage with wireless intelligent network (WIN) and SMTP applications, e.g., 
10 those already otherwise containing a Internet gateway application for routing 
information through an SMTP gateway. Moreover, the MDC allows content 
providers to continue with their current mode of operation without placing the 
carrier's network at risk. The MDC can receive messages using a variety of 
protocols, including SMTP. It automatically routes messages to the 
15 appropriate carrier based on MIN range. Instead of delivering SMTP content 
directly to the carrier, it is delivered to the MDC. The MDC then ensures that 
the content is delivered in a , carrier-friendly , manner. 

MDC can provide the Info Provider with delivery statistics, e.g., 
what percentage of messages are being delivered. 
20 The MDC helps prevent the carrier from being overwhelmed by 

bulk messaging content and provides the following benefits: 

- bulk message traffic is distributed across time 

- messages are delivered over more efficient protocols than SMTP through 
the carrier's Wireless Internet Gateway 

25 • messages are only delivered when handsets are on, thereby eliminating 
network storage and retries 

- messages are delivered with appropriate urgency, delivery receipt, 
expiration times, and billing identifiers 

- individual bulk message queues allow the carrier to limit the number of 
30 messages that can be queued per subscriber 

• bulk messaging can be disabled for individual accounts when subscribers 
churn 

bulk message delivery statistics are available to the carrier via a web 
interface. 

11 
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Acknowledgement of Delivery Receipts 

It is preferred that remote gateways be sent to via a remote 
queue. This is because of the uncertainty about the link IDs which would be 
used by the remote gateway per MIN. Rather, all that is known is that a 
5 gateway takes a certain range of MINs. However, the gateway itself may 
partition out the MINs to be sent via different protocols such as SMPP, TNPP 
or others. That information is preferably not kept at the IDA 318, preventing 
use of the remote SMPP classes. However, the remote queue has no 
provision for sending information back. It is preferred that this ability be 

io provided so as to receive back delivery receipts. 

In accordance with the principles of the present invention, a 
ReceiptNotifier class may be added to the code. When such a ReceiptNotifier 
class detects that a delivery receipt is to go back to the IDA 318 (i.e., a 
hostname or IP is in receiptEmail, receiptMIN or a new receipt field in the 

is Message class 304), it establishes a connection with the IDA 318 and sends 
back the receipt information. 

Two exemplary methods to receive back at the IDA 318 the 
delivery receipt, both involving gateway software running at a remote site to 
recognize first that a delivery receipt is necessary. One was discussed 

20 above, while the other establishes a connection back to the IDA 318 and a 
protocol to use. In accordance with the principles of the present invention, 
RMI techniques, may be used to accomplish this. 

When the remote gateway sees an IDA delivery receipt request, 
it may perform a Naming.lookup() based on the URL in the delivery receipt 

25 field in the Message. It then sends the message name field from the 
Message and the delivery status. Once sent, it can abandon the object it got 
back from the Naming.!ookup() call. 

This implies that the remote gateway will be an RMI client to the 
IDA delivery receipt server. Typically the remote gateway has been acting as 

30 an RMI server. However, this scheme of being a client falls in line with how 
the SMTP delivery receipt is sent, that is, the remote gateway acts as a mail 
client in this case. 
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An IRecelptProxy interface 322 may be added to allow 
communication between the MDC gateway 100 and the IDA 318* The 
DRListener agent 322 in the IDA 318 preferably acts as an RMI server to 
receive the acknowledgements from the MDC gateway class ReceiptNotifier. 

5 The recelptEmall field in the Message preferably contains the hostname to 
respond back to. ReceiptNotifier distinguishes between email addresses and 
host names in this field and sends the delivery receipt accordingly. 

The IDA 318 is configured via appropriate configuration files, 
e.g., an ida.cfg file, an IdaRemoteHostlnfo.properties file, and database tables 

io (described more fully herein below). It is preferred that the IDA 318 use the 
same database as the MDC gateway 100. The MDC gateway 100 and the 
IDA 318 preferably utilize tables and configuration/property files, which should 
be set up correctly. In operation, the setup of MDC and IDA 
configuration/property files is typically the responsibility of an MDC 

15 administrator. Exemplary values for configurable files, are provided herein 
below. 

The MDC 100 and IDA 318 work together to handle the large 
amount of traffic generated by information providers. The MDC 100 
automatically routes messages to the IDA 318 based on if the message is 

20 from an information provider. Instead of delivering SMTP content directly to 
the carrier, the MDC 100 delivers it to the IDA 318. The IDA 318 then 
ensures that the content is delivered in a 'carrier-friendly* manner. 

The MDC Gateway 100 is started using a standard smsgw.sh 
script. The IDA 318 may be started separately with an ida.sh script. The only 

25 necessary dependency between the two programs is the database tables they 
share. This means that either can be started without the other running. 
However, nothing useful happens until both are running. 
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Table 1 describes relevant modules In the MDC Gateway 100. 



Module Name 


Package 


Base36.java 


tcs.ain.smsgw 


Config.java 


tcs.ain.smsgw 


DummyDestination.java 


tcs.ain.smsgw 


IReceiptProxy.java 


tcs.ain.smsgw 


Message.java 


tcs.ain.smsgw 


MessageStoreDB.java 


tcs.ain.smsgw 


ReceiptNotifier.java 


tcs.ain.smsgw 


SMPPReceiptMessage.java 


tcs.ain.smpp 


SMPPResource.java 


tcs.ain.smpp 


SMTPMessageData.java 


tcs.ain.smsgw 


SMTPSession.java 


tcs.ain.smsgw 



Table 1 

5 

Table 2 identifies relevant exemplary modules in an IDAm 318, 
packed in the exemplary embodiment in a "tcs.ain.ida" package and located in 
a directory in the MDC gateway 100, e.g., called "smswebgw". 

Module Na me 

DRListener.java 

DRSubStatusResetter.java 

DeliveryAgentjava 

Hostlnfo.java 

IDA.java 

IDAConfigjava 

IdaDebug.java 

InfoProvidersjava 

MCLRListenerjava 

Messages.java 

RemoteGwInfo.java 

Subscriberlnfo.java ~~ 

SubscriberPoller.java 

Subscribers.java 

Table 2 
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The MDC Gateway 100 uses a number of database tables. The 
following are exemplary configurable tables 500 specifically used by the MDC 
Gateway 100 and the IDA 318. 

5 INFOPROV1DER Configuration Table 

An INFOPROVIDER table provides a list of information 
providers. If an information provider is on this list, the MDC Gateway 100 will 
route a relevant message to the IDA 318. The INFOPROVIDER table Is used 
only by the MDC Gateway 100. 
io The INFOPROVIDER table is preferably configured by an 

appropriate system administrator. 



Column 


Data Type 


Null? 


i Notes 


MSGSENDER 


CHAR(150) 


N 


Should match what the 
information provider puts In 
the sender field in mail 


LASTUPDATE 


NUMBER 


Y 


Currently unused. Should 
represent time when row was 
inserted 


INFOPROVIDERID 


NUMBER(9) 


Y 




PROVIDERNAME 


VARCHAR2(50) 


Y 




SERVERID 


VARCHAR(50) 


Y 




SERVERPASSWORD 


VARCHAR2(50) 


Y 





Table 3 

15 

LINKID NPANXX Configuration Table 

A LINKID_NPANXX configurable table, used by both the MDC 
gateway 100 and the IDA 318 associates a MIN with a earner's remote 
gateway. Link IDs are defined for each carrier in a GWDest.properties file 
20 from smswebgw/smsgw. The IdaRemoteHostlnfo.properties file mentioned in 
the next section should align with the link IDs. 
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Column 


Data Type 


Null 

? 


Notes 


LINKID 


NUMBER(2) 


Y 


This number is an ID 
assigned to each carrier with 
a remote gateway to which 
the IDA can send messages. 


NPA_NXX 


VARCHAR2(6) 


N 


Represents tne first 6 digits 
ofaMIN and Is used to 
assign a MIN to a remote 
gateway. 



Table 4 

5 MESSAGES Configuration Table 

A MESSAGES table contains information about a message 
being senl. The MESSAGES table may be used by both the MDC gateway 
100 and the IDA 318. 



io 



Column 


Data Type 


Null? 


MSGTYPE 


NUMBER(2) 


Y 


MSGSOURCE 


NUMBER(2) ' 


Y 


MSGSTATUS 


NUMBER(2) 


Y 


MSGSUBSTATUSDESC 


VARCHAR2(255) 


Y 


MSGMIN 


VARCHAR2(30) 


Y 


MSG CALLBACK 


VARCHAR2(30) 


Y 


MSGSENDER 


VARCHAR2(150) 


Y 


MSGSUBJECT 


VARCHAR2(255) 


Y 


MSGTEXT 


VARCHAR2(2000) 


Y 


MSGSRCADDR 


VAKCHAR2(150) 


Y 


SMSCMSGID 


VARCHAR2(10) 


Y 


RECEIPTEMAIL 


VARCHAR2(70) 


Y 


RECEIPTMIN i 


VARCHAR2(30) 


Y 


RECEIPTCALLBACK 


VARCHAR2(30) 


Y 


MSGNAME (the unique 
identifier (key)) 


VARCHAR2(20 


N 


SRCGWID 


VARCHAR2(5) 


Y 


MSGARRIVE 


NUMBER 


Y 


MSGSENT 


NUMBER 


Y 


MSG FINAL 


NUMBER 


Y 


MSGSUBMIT 


NUMBER 


Y 


MSGEXPIRE 


NUMBER 


Y 



Table 5 



16 



SUBSTITUTE SHEET (RULE 26) 



WO 01/78422 



PCT/US01/11795 



SUBSCRIBERS Configuration Table 

A SUBSCRIBERS table is used internally by the IDA 318. It 
keeps track of subscribers that have been sent messages by an information 
provider. The SUBSCRIBERS table is used by both the MDC Gateway 100 
s and the IDA 318. 



Column 


Data Type 


Null? 


Notes 


SUBSCRIBERMIN 


VARCHAR2(30) 


N 




STATUS 


NUMBER(2) 


N 


Internal value (0-offline, 1- 
online, 2-unknown) 


LASTSTATUSUPDATE 
TIME 


NUMBER 


Y 


Last time the status was 
changed 


LASTMSGTIME 


NUMBER 


Y 


Last time the subscriber 
received a message 



Table 6 



10 There is only one trigger in the exemplary embodiments defined 

for the IDA 318, called subsc_update. Whenever a message is added to the 
MESSAGES table, the subscriber is added or updated in the SUBSCRIBERS 
table if the message is from an information provider. This may be indicated, 
e.g., by bit 6 being set in an msgsource field. 

15 

IDA Configuration File 

An ida.cfg file contains parameters that control the behavior of 
the IDA program 318. It is preferred that the ida.cfg file reside in the same 
directory as the executing IDA program 318. Table 7 shows exemplary 
20 parameters and values of an ida.cfg file, in accordance with the principles of 
the present invention. 



Parameter | Purpose | Field Value | Field Explanation 


General Parameters ^ 


SubscriberStrategy 


Strategy used to 
find subscriber 
status * 


DELIVERY REC 
EIPT (default) 


Have the remote 
gateway request a 
delivery receipt 


MCLR 


Use mobile chat 
location register 
(not implemented 

yet) 


debugmode 


Used to set the 
IDA to print run- 


true 


Turn on run-time 
messages 
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Parameter 


Purpose 


Field Value 


Field Explanation 




time debug 
messages 


false (default) 


Turn off run-time 
messages 


RemoteQueueNa 
me 


Name of remote 
queue to send 
messages to 


RemoteQueue 
(default) 


only changed for 

debugging 

purposes 


DRServerName 


Name of service 
to receive delivery 
receipts 


DeliveryReciptSer 
ver 


Onlv chanaed for 

debugging 

purposes 


LogFileName 


Name of file to 
receive log 
messages 


text string 


Absolute or 
relative path to a 
logger file 
Directory must 
exist already. 


Database Parameters 


DbClass 


The driver to use 
for talking with the 
database 


text string 


Class name to use 
for database 
access. System 
must be configured 
with proper drivers 


DbUrl 


the reference to 
the database and 
machine where 
database resides 


text string 


Legal URL for the 
driver 


DbAccount 


Account name 


text string 




DbPassword 


Password to 
account 


text string 




Delivery Setup Parameters 


MsgGroupSize 


Number of 
messages to 
send to a 
subscriber at a 
time 


number 




MsgSendRate 


Number of 
messages to 
send per minute 


number 




MsgHoldTimes 


Time to not send 
msgs (local time). 
Repeat the line 
for multiple 
periods 


Start time and 
end time in 24 
hour format, 
HHMM 


Must have start 
and end times. If 
end is less than 
start, then cross 
over of midnight is 
assumed. 


Polling/Expiration Rates Parameters 


SubscnberOnlineTi 
me 


Maximum number 
of seconds a 
subscriber stays 
online 


number 




SubscriberOffiineTi 
me 


Maximum number 
of seconds a 
subscriber stays 


number 
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Parameter 


Purpose 


Field Value 


Field Explanation 




offline 






SubscriberXmitPoll 
Time 


Time between 
checks for 
subscriber 
messages 
(seconds) 


number 


This must be less 
than half the value 
of the smaller of 
SubscriberOnlineTi 
me & 

SubscriberOfflineTi 
me 


SubscriberExpireTi 
me 


Hours without a 
message before a 
subscriber is 
purged. 


number 





Table 7 



IdaRemoteHostlnfo.propertles File 

5 This file relates a link ID for a MIN to a remote host name, and 

whether it can support delivery receipts. A leading number followed by an 
underscore corresponds to the link ID in the LINKID_NPANXX table and the 
GWDest.properties file. 

The form of an entry in the disclosed 

10 IdaRemoteHostlnfo.propertles file may be, e.g., <linkid>_<parameter>=value. 
Permissible parameters and their values for the exemplary 
IdaRemoteHostlnfo.properties files are shown in Table 8. 
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Parameter 


Purpose 


Values 


camerName 


Short form of the carrier 
name 


Text string 


carrierNameLo 
ng 


Long form of the carrier 
name 


Text string 


carrierHostna 
me 


The host name of the 
machine with the carrier's 
remote gateway 


The name must be resolvable via 
DNS. 


receipts upport 
ed 


Indicates if remote 
gateway can send 
delivery receipts. The 
gateway must be running 
the updated version of 
TCS gateway software 
and have enable_web in 
smscgwxfg set to true 


true, yes, false or no 



Table 8 



Table 9 is an example showing how the carrier data may be 
formatted in the IdaRemoteHostlnfo.properties file. 



10 



0_carrierName=AT 
0_camerNameLong=AirTouch 
0_carrierHostname=Sms2way.airtouch.net 
0_receiptSupported=yes 

3_camerName=BAM 
3_carrierNameLong=Bell Atlantic Mobile 
3_camerHostname=smsc.bam.com 
3_receiptSupported=yes 

24_carrierName=FR 
24_carrierNameLong=Frontier 
24_carrierHostname=msg JrontiercelIuIar.com 
24_receiptSupported=no 



Table 9 

MDC Configuration File 

An smscgw.cfg file may be used to configure the software of the 
MDC Gateway 100. The disclosed MDC Gateway 100 requires several 
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parameters to be set to route short messages from information providers to 
the IDA 318. The Remote Gateways that the IDA 318 talks to preferably have 
a flag such as "enable_web" set if they are to be capable of sending delivery 
receipts back to the IDA 318. Tables 10 and 1 1 show exemplary parameters 
5 in an MDC Configuration File, In accordance with the principles of the present 
Invention. 



smscgw.cfg 


MDC Gateway Configuration 


Parameter 


MDC Value 


Notes 


enable_mdc 


yes 


Causes check for information provider 
messages 


enable_smtp 


yes 


Remote gateway routes mail to the IDA. 


enable web 


yes 


Allows remote queue calls via RMI 


MessageStore 
Type 


DB 


IDA can only work with database activated 


Table 10 


L smscgw.cfg Remote Gateway Configuration 


Parameter 


MDC Value 


Notes 


enable web 


yes j 


Allows remote queue calls via RMI 



Table 11 



While the invention has been described with reference to the 
is exemplary embodiments thereof, those skilled in the art will be able to make 
various modifications to the described embodiments of the invention without 
departing from the true spirit and scope of the invention. 
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CLAIMS 

What is claimed is: 

1 . A method of providing tfoss-carrier messaging, comprising: 
intercepting a short message from a sending subscriber of a first 

5 wireless carrier intended for transmission over an Internet; 

storing said intercepted short message in an individual 
subscriber queue located in a gateway; 

determining a destination of said short message based on a 
mobile identification number (MIN); and 
to automatically delivering said short message to said receiving 

subscriber of a second wireless carrier different from said first wireless carrier 
without transmission over said Internet; 

whereby said short message is transmitted between different 
wireless carriers without requiring transmission over an Internet. 

15 

2. The method of providing cross-carrier messaging according 
to claim 1 , wherein: 

said short message is transmitted to said second wireless 
carrier using RMI protocols. 

20 

3. The method of providing cross-carrier messaging according 
to claim 1 , wherein: 

said short message is transmitted to said second wireless 
carrier using SMPP protocols. 

25 

4. A method of automatically delivering a short message to a 
mobile device, comprising: 

determining when said mobile device has powered up by 
inspecting SS7 data from a home location register relating to said mobile 
30 device; and 

automatically delivering said short message to said mobile 
device when said mobile device has powered up based on Information 
obtained from said inspection of SS7 data. 
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5, A method of automatically delivering a short message to a 
mobile device, comprising: 

determining when said mobile device has powered up by 
inspecting delivery receipt data from a short message servicing center relating 
5 to said mobile device; and 

automatically delivering said short message to said mobile 
device when said mobile device has powered up based on information 
obtained from said inspection of said delivery receipt data. 

io 6. Apparatus for providing cross-carrier messaging, comprising: 

means for intercepting a short message from a sending 
subscriber of a first wireless carrier intended for transmission over an Internet; 

means for storing said intercepted short message in an 
individual subscriber queue located in a gateway; 
is means for determining a destination of said short message 

based on a mobile identification number (MIN); and 

means for automatically delivering said short message to said 
receiving subscriber of a second wireless carrier different from said first 
wireless carrier without transmission over said Internet; 
20 whereby said short message is transmitted between different 

wireless carriers without requiring transmission over an Internet. 

7. The apparatus for providing cross-carrier messaging 
according to claim 6, wherein: 

25 said means for automatically delivering said short message 

transmits said short message to said second wireless carrier using RMI 
protocols. 

8. The apparatus for providing cross-earner messaging 
30 according to claim 6, wherein: 

said means for automatically delivering said short message 
transmits said short message to said second wireless carrier using SMPP 
protocols. 
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9. Apparatus for automatically delivering a short message to a 
mobile device, comprising: 

means for determining wheh said mobile device has powered up 
by inspecting SS7 data from a home location register relating to said mobile 
5 device; and 

means for automatically delivering said short message to said 
mobile device when said mobile device has powered up based on information 
obtained from said inspection of SS7 data. 



10 



10. Apparatus for automatically delivering a short message to a 
mobile device, comprising: 

means for determining when said mobile device has powered up 
by inspecting delivery receipt data from a short message servicing center 
relating to said mobile device; and 
15 means for automatically delivering said short message to said 

mobile device when said mobile device has powered up based on information 
obtained from said inspection of said delivery receipt data. 



20 
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